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The present invention relates to a process and a system for controlling the 
delivery of digital works across a communications channel such as the internet in cases in 
which payment is required for the content of said digital works as received by a client. In 
particular, it relates to a transmission protocol comprised in said system suitable for said 
5 process. 



1 

Internet payment process based on return traffic 



Intemet traffic is characterized in that it is a Best Effort type of service. This 
means that data packets sent across the intemet have a probability of being lost or being 
delayed while en route. Measures to solve this are generally referred to in terms of Quality of 
10 Service, or QoS. 

A system of the above-mentioned type is known from docimient EP-0715247. 
This document provides a comprehensive description of rendering systems, stractures of 
digital works, attachment of user rights to a digital work, repositories, credit servers, user 

1 5 rights language and repository transactions which said system can comprise. 

The transmission protocol disclosed in said document is directed to preclude 
certain failure modes, such as malicious or accidental interferences on the conmiunications 
channel. Its stated object is that there should be no time at which a party to the 
communications can break a connection as a means to avoid payment after using a digital 

20 work. A complete digital work needs to be delivered before payment for the same is 
effectuated. In other words, the transactions with delivery are atomic by nature. 

In regard of the operation, said document discloses that if there are several 
blocks to be sent, the server waits until receiving an acknowledgement message from the 
requester (client). When an acknowledgement message is received the server sends the next 

25 block to the requester and again waits for acknowledgement. Transmission thus occurs in a 
block-by-block mode of operation. The requester (client) also repeats the same cycle of 
states. 

If there are no more blocks to send, the server commits to the transaction and 
waits for the final acknowledgement message. If there is a communications failure before the 
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2 19.12.2000 
server receives the final communications message, it still commits to the transaction but 
includes a report about the event to its credit server. This report serves two purposes, one of 
which is to help legitimize any claims by a user of having been billed for receiving digital 
works that were not completely received. There is a similar protocol on the requester (chent) 
side; the key property being that both the server and the requester cancel a transmission if it 
is interrupted before all of the data blocks are delivered and commit to it if all of the data 
blocks have been deUvered. 

The atomic nature of such transactions with delivery poses several problems 
when the digital works concerned are large or when content has to be streamed during a long 
period of time. Such a situation arises in regard of payment for e.g. audio and/or visual or 
other multimedia material first after completion of reception of the whole contents thereof A 
requester (customer) may not view (i.e. receive) the whole digital work before having setded 
payment for the same. One problem relates to the probability of disruption of communication 
which is greater in proportion to the size of, and thus to the time needed for transferring, the 
digital work. Another problem relates to the need for a report to the credit server, both from 
the server as well as the requester, m regard of legitimizing payment for the digital work. Yet 
another problem relates to the server not being able to delete any transferred digital work 
until receiving the final acknowledgement from the requester, but also being unable to use 
the file in regard of prevention of loss of data. This requires a comprehensive protocol 
comprising e.g. two-commit phase or a level of encryption without any real gain in 
accountability. 

There is yet another problem related to the atomic nature of said transactions. 
This problem concerns the real-time processing requirement. Since ddivery of continuous 
media requires real-time handling (if delivery thereof isn't a download operation), the atomic 
payments need to proceed at the speed of delivery, e.g. at 20 ms per packet, such that 
processes or functions in regard of the same do not lead to discontinuities ('hiccups' or 
hitches) in the media presentation. 

It is an object of the present invention to simplify the transmission protocol for 
30 said processes and systems suitable for said processes. 

It is another object of the invention to provide for a transmission protocol 
which is executable on a server computer and a client computer (so-called end-hosts; thus 
for end-user operations). 
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3 19.12,2000 
It is yet another object of the present invention to provide for a transmission 
protocol which entails payment for all received digital packets even in the case of 
discontinued transmission of the digital work. 



5 According to one aspect of the invention one or more of the stated objects is or 

are achieved by a process for controlling delivery of digital works across a communication 
channel such as the intemet as specijSed in claim 1 . 

The basic novel and inventive concept is to have the stream of 
acknowledgement codes (ACK) which are known from available transmission protocols also 

1 0 serve the function of payment tokens. Central to this concept is the linking or association of 
payment to a streaming delivery, i.e. to a regular flow of packets lasting for some period of 
time. Payment advances along with the progress of that time period; delivery of content 
discontinues upon non-advancement of acknowledgement of receipt, thus upon non- 
advancement of payment for the content. 

15 The related technical advantage is that it makes use of an existing and clear 

audit trail that the client has received a digital work (or a part thereof), as substantiated and 
embodied by the successive stream of acknowledgement codes, to regulate payment for the 
content of the packets received A further technical advantage is that by linking payment for 
content to this already available successive stream of acknowledgement codes, regulation of 

20 payment for the content delivered is simplified. As a result, the need for adding layers to the 
transmission protocol in regard of payment tokens, commitment or encryption is eliminated. 
A less strict transmission protocol or integrity mechanism therefore suffices. A client simply 
pays for each packet that he himself has already acknowledged as having received in good 
order. And a client pays as he receives. This results in a less redundant, thus faster execution 

25 of payment transactions. It thus offers a greater efficiency to both the server and the client. 
It will be noted that the temi transmission or transport protocol also 
encompasses streaming protocols. Streaming is not limited to transmission or transport 
protocols; at least server and client application processes also play a role in this regard. 

According to a further aspect of the invention one or more of the stated objects 

30 is or are achieved by making use of a credit window during transmission of digital packets by 
the server as specified in claim 3. This follows from overcoming the prejudice that in regard 
of payment of content of digital work, transmission of the whole digital work has to be 
completed before being able to definitely settle payment for the same. The related technical 
advantage is that the server allows for an amount of credit which is very small compared to 
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the size of the whole digital work. This entails that the server (or content provider) will not 
suffer any great loss in case of non-payment for the packets sent in credit if no further 
acknowledgement codes were to be received from the client (requester). The size of the credit 
window is adaptable to the actual transmission conditions and the policy of the transaction. 

5 

The concept of a window as such is known for the use of controlling the flow 
rate of the transmission. See for example D.P. Bertsekas and Gallager, "Data 
Networks", Prentice-Hall, Inc., NJ, USA, 1992, chapter 6.2. The TCP protocol of the Internet 
is based on window control. That is, the 'transit window* is known; the concept of a 'credit 

1 0 window* for the payment, in the present example in regard of streaming content of (parts of) 
digital works is novel. 

The Transmission Control Protocol (TCP) allows for segmentation of the data 
to be transmitted into IP packets and for numbering of the hytes. Using these numbers the 
receiver of a TCP connection re-orders the received packets, in case IP has delivered them 

1 5 out of order. It further sends an ACK packet (acknowledgement) back to the sender for each 
received packet of which the preceeding packets have also been received. The TCP sender 
uses these ACKs to determine which packets need to be resent in order to repair for losses, 
and by that to turn the IP best-effort delivery into a reliable end-to-end transport. A packet is 
retransmitted after a time-out period has expired during which an expected ACK has not been 

20 received, or when its previous packet has been ACK-ed three tunes. The time-out period is 
based upon an estimate of the Round Trip Time (RTT). Duplicate ACKs indicate that packets 
succeeding the missing one do have been received, which in turn is an indication that there is 
no further congestion in the transport channel. 

Other alternatives of informing the sender on missing packets is by sending 

25 NAKs, Negative ACKs, or SACKs, Selective ACKs. 

TCP also makes use of the ACKs to determine its transmission rate. This rate 
follows as the nimiber of packets en route for which acknowledgement is required, the 
window, relative to tiie RTT. The window is increased upon successful transmission, while 
conversely lost packets decrease it. In this way TCP adapts its transmission rate to the 

30 available bandwidth. 



The invention also provides a process for use as set out in claim 5. 

The invention further provides a method as set out in claim 6. 

The invention fmther provides a computer programme as set out in claim 9. 
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These and other aspects of the invention will be apparent from and elucidated 
with reference to the embodiment(s) described hereinafter. 

5 Figure 1 depicts a general set-up of the process according to the invention. 

Figure 2 depicts the operations of the monitor according to Fig. 1 . 
Figure 3 depicts the role of protocols in traffic between the server and the 

client. 

1 0 According to an embodiment of the invention, following a request from a 

client to a server, e.g. during a session initiation phase, there is a negotiation phase between 
the two in regard of the setting-up of a retum traffic of acknowledgement codes and payment 
tokens. Agreement is to be reached on the same and also on other technical aspects such as 
type of content, type coding, IP addresses, port nimibers, etc. A following step in the process 

1 5 according to the invention entails that a digital work (1 00), for example with multimedia 

content, is formed into a number of digital packets (lOOi . . . lOOz) at a server (200). The size 
of a packet (100i.j...z) is small as compared to the size of the digital work (100) concerned. 
For example, in the case of audio content, the size of the packets would be small enough to 
be able to comply with transmission at 20 ms intervals. The server (200) comprises sender 

20 software and/or hardware components (210) which it uses to transmit the packets (lOOi ... 
lOOz) to a client (300). The client (300) stores (310) or reproduces (320) or otherwise 
processes the packets it receives. It acknowledges (330) the packets received by sending 
acknowledgement codes (ACKs) to the server. A monitor (220) in the server comprising 
receiver soflware and/or hardware components(not shown) receives the acknowledgement 

25 codes (ACKs) sent by the client and based on these it controls the continuation of the 

transmission of packets. To this end the monitor (220) issues control commands to the sender 
software and/or hardware (210). There is continuation of the streaming of said content by the 
server only if the acknowledgement code(s) requested from the client is (are) received as 
specified by the server, otherwise there is discontinuation of the streaming transmission by 

30 the server if the initiated successive retum traffic of acknowledgment codes from the client to 
the server is dismpted. The received acknowledgements are also accimiulated in a payment 
registry (not shown) that handles the further billing. Note that it is not necessary to have one 
ACK packet returned by the client for each and every data packet sent by the server. It will 
be apparent that other mappings can serve as well. 
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Figure 2 provides an elaboration on the control operations of the monitor (220) 
according to Figure 1. Figure 2 depicts the order of the consecutive packets of the media 
stream. The packets upto the packet indexed N-1 have been transmitted. T nimiber of packets 
have been transmitted, but are yet to be acknowledged by the client, i.e. these packets are in 
5 transit. The server is set to accept that at any given instance upto W number of packets may 
not yet be acknowledged. If W packets are not acknowledged in time, the server will 
discontinue the transmission. 

The monitor (220) administrates the number of packets bemg transmitted, and 
the number of packets which are in transit. The packets being transmitted are labelled as 
1 0 either Successful or Unsuccessful, depending on whether an ACK has been received for that 
packet or not, respectively. Each packet is also associated with a transmission time and a re- 
transmission deadline. The former indicates when the packet will be transmitted during 
normal operation; the latter indicates whether re-transmission is useful such that the client 
can still receive the packet in time for reproduction, (hi regard of a download operation this is 
1 5 always the case.) These times do not necessarily increase in proportion to the number (order) 
of the packets. In this embodiment and only by way of example it is to be assumed that these 
times do increase proportionately with the packet order in question. 

In one embodiment of the invention, acknowledgement of the data received 
can be purposively made to be time-limited. An example is the case in which listening to 
20 audio material or viewing video material is granted on pre-listening or pre-viewing 

conditions, respectively. Acknowledgement is restricted and the server discontinues when the 
time-limit set has passed. During the pre-listening or pre-viewing period, a client or user is 
offered the possibility of confirming the transaction and, if not confirmed as required, no 
further transmission is allowed. 
25 It is conceivable that there is a different payment policy for the content 

received during a pre-view or pre-listen period. It is also conceivable fliat said content be 
treated differently in regard of payment policy after any re-setting of the credit window. 

In another embodiment of the invention, the credit window can initially be 
large. It is possible to set the size of the credit vraidow one or several times again after the 
30 pre-view or pre-listen period. An increment in the size of the credit window would relate to 
the number of ACKs which would not need to be received by the server during the pre-view 
or pre-listen or any other type of trial period. It is also possible to consider and implement a 
decrement in the size of the credit window if it so required or desired. Further actions on the 
part of a client, e.g. acknowledgement by the client before the trial period lapses, can be 
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technically implemented in a decision tree or protocol. In yet another embodiment, the credit 
window mechanism can be initiated only after the trial period has lapsed. This would require 
synchronisation with the client side of the process and the system for implementing the same. . 

User confimiation can be given in several ways. For example, if there is no 
action taken by the client or user, the server will confirm proper receipt of the data packets 
when the file has been delivered. This in analogy to "no news fi-om the client means good 
news (=proper receipt), therefore the transaction is in order." A second example is generation 
of action in regard of good delivery of the data packets at the end of recording by the client or 
user. Said action could be with respect to any active move related to the player device. It will 
be readily apparent that there could be need for discriminating between all sorts clicks or 
other actions taken by the user, for otherwise no simultaneous actions could be undertaken 
during delivery of the data packets. A third example would entail the facility of a button 
denoted e.g. "received properly" on a user screen and/or a remote control facility. All sorts of 
user interfaces could be applied in this regard. 

Figure 3 depicts the role of various examples of protocols in the traffic 
between the server and the client It shows some examples of protocols usable for the 
different exchange phases in tiie traffic between the server and the client. During the session 
initiation and negotiation phases, HTTP/TCP protocols can be used; negotiation and 
initiation/configuration can be exchanged using SDP; during session control and media 
coiitent transport RTSP/ TCP and RTP/UDP protocols can be used. 

With reference to the state of operation shown in Figure 2, the monitor (220) 
updates the various pointers to the various window boundaries shown in Figure 2 according 
to the following algorithms (these algorithms are only by way of example): 

Upon reception of ACKn* 

- increment ACK pointer by one to position N 

- increment credit window pointer by one to position N+W 

- mark location N as Successful 

Upon reception of an ACKm+p, P>0: 

- increment credit window pointer by one to position N+W 

- mark location N+P as Successful 
-forp=OtoP-l do: 

- if retransmission deadline of packet N+p has passed: 
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- increment ACK pointer to position N+p (as said, in this 
example a monotonous increase in retransmission 
deadlines is assumed) 

- mark location N+p as Unsuccessful 

5 - otherwise (retransmission deadline of packet N+p has not yet 

passed): 

- retransmit packet N+p (retransmission may also be 
initiated by other mechanisms like a time-out; similarly, 
a retransmission may require reception of more than one 

10 ACKNHhP, P>0) 

Upon reception of an ACKn-m, M>0: 

- if location N-M was marked Unsuccessful: 
- mark location N-M as Successfiil 
15 - increment credit window pointer by one to position N+ W 

Packets are transmitted at a regular pace, i.e. the packet sent pointer is 
incremented by one, opening the transit window, at a regular pace. A packet is transmitted if 
it is in both the transit and credit window. In normal operation, as exemplified in Fig. 2, it 

20 - means that the packet N+T is sent when its transmission time passes. Otherwise, in case its 
transmission time has passed, but not its transmission deadline, the packet is sent when the 
credit window opens to include that packet. In principle, if the transmission deadlme has 
passed, the packet is marked Unsuccesful. In such a situation, the whole transmission is 
deemd to have been dismpted, 

25 In regard of the size of the credit window W: the number of open ACK codes, 

i.e. for the data packets sent receipt of which have not yet been acknowledged by the client, 
can be set to be incremented if a certain number of (additional) ACKs have been received or 
if the data packets have been sent and received for a certain period of time. Conversely, the 
credit window can be decremented if the transmission is not occurring smoothly. 

30 Payment is according to the number of Successful counts. The choice of T is 

such that retransmissions of lost packets can be done within the given deadline. The choice of 
W is dependent on the credit that the transaction is willing to accept. W should be small, i.e. 
insignificant, compared to the total number of transmitted packets. 
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Suppression of ACKs by the client will close the credit window W. 
Eventually, the transmission will be discontinued. In an error-prone transmission channel, 
ACKs will not be received, either because the packet was not received, or because its ACK 
was lost. This will prohibit the credit window to open. If in addition the retransmission 
deadlines are too critical, the transmission may be discontinued, even though the client is 
acknowledging all packets it does receive. 

Losses are imdesirable because of the associated distortion the client will 
experience in the reception. Window closing due to sustained losses can be circumvented by 
a well-dimensioned choice of W, compared to T. Sustained loss rates can be circumvented in 
the negotiation phase during establishment of the connection. Say, for example, that the client 
and server agree on an acceptable loss rate of e%. Aside from possible transmission of 
additional redundancy packets, it implies tiiat the credit window pointer is incremented by 
one after every hundred/e (the reciprocal of e%) packets being marked UnsuccesM 
(corrected for packets being re-marked to Succesful). 

Maskerading by a client can be prevented by having the server send so-called 
"challenges" along with the data packets to the client and by having the client to return 
responses to the same along with the return traffic of acknowledgement codes. 

The invention also extends to computer programmes, in particular to computer 
programmes on or in a carrier, adapted for putting the invention into practice. The 
programme may be in the form of source code, object code, a code intermediate source and 
object code such as in partially compiled form, or in any other form suitable for use in the 
implementation of the processes according to the invention. The carrier may be any entity or 
device capable of carrying the programme. 

For example, the carrier may comprise a storage medium, such as a ROM, e.g. 
a CD ROM or a semiconductor ROM, or a magnetic recording medixmi, e.g. a floppy disk or 
a hard disk. Also, the carrier may be a transmissible carrier such as an electrical or optical 
signal which may be conveyed via electrical or optical cable or by radio or by other means. 

When the programme is embodied in a signal which may be conveyed directly 
by a cable or other device or means, the carrier may be constituted by such cable or other 
device means. 

Alternatively, the carrier may be an integrated circuit in which the programme 
is embedded, the integrated circuit being adapted for performing, or for use in the 
programme, of the relevant process steps. 
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The process, constituent protocol thereof and system and computer 
programme for implementation of the same as described above are generally applicable m 
cases in which micropayments come into play. Some suitable and in no way delimiting 
examples relate to devices with downloading or streaming capabilities which are connected 
to communications channels such as the internet, e.g. a juke box. The general novel and 
inventive concept described above can also be made suitable for use with television and set- 
top boxes. 



CLAIMS: 
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1. Process for controlling delivery of digital works across a communication 
channel such as the internet whereby there is to be paid for the content of said digital works, 
whereby the process is executable on a server computer (200) and a client (requester) 
computer (300) (so-called end-hosts), said process comprising the steps of: 

a) a set of negotiation steps in which the client and the server agree to and configure for 
delivery of the content of a digital work; 

b) creating at the server and executing a regular flow of packets (100i..i ..z) lasting for some 
period of time (so-called "streaming")* whereby the packet size is small with respect to 
the total size of said digital work, of said content from the server to the client using a 
transmission or transport protocol, whereby the client is requested to acknowledge the 
received content; 

c) initiation of a return traffic of at least one acknowledgement code (ACK) by the client to 
the server whereby a payment token is associated with each acknowledgement code or 
with a number of acknowledgement codes; 

d) validation by the server that each acknowledgement code requested of the client is 
received by the server; 

e) continuation of the streaming of said content by the server only if the acknowledgement 
code(s) requested of the client is (are) received as specified by the server; 

f) accumulation of the payment tokens associated with tiie acknowledgement codes received 
firom the client in a pay-for-each-packet-received-as-acknowledged-by-the-client mode of 

operation; 

g) arrangement of billing of and payment by the client for all received packets on the basis 
of at least said accumulated payment tokens. 

2. Process for controlling delivery of digital works across a communications 
channel according to claim 1, characterized in that in step (c) or step (e) acknowledgement by 
the client is associated with at least one packet of the forwarding flow from the server to the 
client. 
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3 Process for controlling delivery of digital works across a communications 
channel according to claim 1 or claim 2, characterized in that in step (e) continuation of the 
streaming of packets with content by the server occurs whereby a certain number of packets 

5 may be transmitted while a number of acknowledgement codes in transit less than or equal to 
another pre-detennined number of acknowledgement codes encompassed in the credit 
window have not yet been received by the server. 

4 Process for controlling delivery of digital works across a communications 

10 channel according to claim 3, characterized in that the size of said credit window is adaptable 
to the number of acknowledgement codes received from the client. 

5, Process according to any of claims 1-4 for use in conducting business 

operations or commercial transactions, comprising regulation of payment based on received 
15 return traffic. 

6 Process according to claim 5 for use in conducting business operations or 

commercial transactions, whereby in addition billing is dependent on the transmission rate 
and/or on the length of the transmission session and/or on the loss rate of the transmitted 
20 digital packets. 

7. A method of sending and/or receiving packets by a system comprising a server 

and a client, said method comprismg one or more steps includmg at least step ( c) of a 
process according to any of claims 1-6. 

25 

g. A method of sending and/or receiAfing packets by a server, comprising one or 

more steps including at least step (c) or step (e) of a process according to any of claims 1-6. 

9. A method of sending and/or receiving packets by a client, comprising one or 
30 more steps including at least step (c) or step (e) of a process according to any of claims 1-6. 

10. A computer prognunme comprising instructions, which instructions include at 
least code defining the processes or functions to be performed with respect to 
acknowledgement codes and payment tokens associated with said acknowledgement codes, 




for causing a programmable processing apparatus having or being connected to transmission 
hardware to become operable to execute the method according to claim 7. 



11. A computer programme comprising instructions, which instructions include at 
5 least code defining the processes or functions to be performed with respect to 

acknowledgement codes and payment tokens associated with said acknowledgement codes, 
for causing a programmable processing apparatus having or being connected to transmission 
hardware to become operable to execute the server-related steps of the method according to 
claim 8. 

10 

12. A computer programme comprising instructions, which instructions include at 
least code defining the processes or functions to be performed with respect to 
acknowledgement codes and payment tokens associated with said acknowledgement codes, 
for causing a programmable processing apparatus having or being connected to transmission 

1 5 hardware to become operable to execute the client-related steps of the method according to 
claim 9. 

1 3 . Computer programme according to any of claims 1 0- 1 2 on or in a carrier 
comprising a storage medium. 

20 

14. Computer programme according to any of claims 10-12 with or in a 
transmissible carrier such as an electrical or optical signal 

1 5. Transmission entity of which a computer progranune according to any of 
25 claims 10-12 forms a component. 

16. A system for controlling delivery of digital works across a commiinication 
channel such as the intemet whereby there is to be paid for the content of said digital works, 
whereby the system is operable on a server computer and a client (requester) computer, 

30 whereby the system comprises: 



one or more repositories for storing and exchanging digital works, each of said digital 
repositories comprising: 

storage means for storing digital works and usage rights attached to said digital works; 
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transaction processing means having a requester mode of operation for requesting access to a 
digital work, said request specifying a usage right, to which usage right is attached a payment 
token, and a server mode of operation for processing requests to access said requested digital 
work based on said usage right specified in said request and usage rights attached to said 
5 digital work; 

transmission means for transmission of the digital work fiom the server to the requester, said 
transmission means operable under a protocol suitable for carrying out the process according 
to any of claims 1-6. 
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ABSTRACT: 

2 2 1Z. 2000 

@ 

The invention relates to an internet payment system based on return traffic. In 
regard of payment for content delivered across the internet an aspect of the invention 
provides for initiation of an explicit return flow of packets. Reception by the server of these 
return packets entails reception of payment tokens of the client by the server and a sign to the 
5 server to continue with the delivery of the content. 

Maskerading by the client can be prevented by sending challenges along with 
the data packets and by having the client to send responses to the same along with the return 
packets. 



10 Fig. 1. 
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